Users of handheld wireless devices now have available to them services that provide notification of time-sensitive events and information. Content providers generate content for notifications. The content is typically electronically stored to a data source and made available via a service-oriented architecture, for delivery via a network to one or more subscribing users electronically. For example, a news organization may provide notification content relating stock prices, breaking news, weather conditions, traffic conditions, etc. A user's expressed interest to receive electronic notifications for a particular class of content is generally called a notification subscription. Such subscriptions often are made between the end user and the content provider that sends the notifications. Event-driven notifications of this type are often referred to as alerts.
There is no built-in support in a service-oriented architecture (like Web services) to inform a client, such as a subscribing users wireless device, of its state changes. This is an important distinction for a service-oriented architecture as most computing systems are asynchronous in nature and the client needs to acquire such a change of the state through some asynchronous mechanism.
The client needs to know the information of interest is posted or when there is a change in the status of the posted content. Such information ideally needs to be “pushed” over the network to the client either periodically or when certain predefined events occur. Some examples of possible push situations are arrival of new e-mail, stock market information, multi-user game updates, etc. Typically, the information pushed to the client is a push notification which returns the updated data in response to an earlier submitted subscription message from the client device. Alternatively, a push notification can be a code (e.g. a Boolean value), which informs the client device that a detailed response is available for retrieval from the Web service.
Invoking Web service operations from a wireless device using synchronous communication methods exclusively is considered expensive and impractical. Most Web services employ protocols with a large footprint (e.g. SOAP) and are designed mostly for synchronous communication (“request/response” or “pull”) on wired networks. In a synchronous scenario, the client initiates the communication by sending a request to the server and waits to receive the response on the same connection. However, in the wireless space, where resources and bandwidth can be limited and data traffic cost can be high, synchronous communication is undesirable.
A common technique to deliver content to the wireless device is when the user of the device requests or “pulls” the content from the network. In other words, the content of interest (or the indication whether the content is present) is available in the network, but the user needs to issue a retrieval request to access the information. Current wireless systems operate by the wireless device repeatedly polling the server for data to satisfy the request. From a practical point of view, wireless communications can have higher cost than wired communications and usually are characterized by higher latency times, making a “pull” from a wireless device inherently expensive. Also, slow connection times sometimes might be annoying to a user, such as extended wait times to process the request, including periodic loss of services connection during the wait time.
While asynchronous Web services would be an ideal choice for a wireless alert or notification system there are a number of factors limiting the use of asynchronous Web services. Typically, the development effort and the skills required by a programmer to build an asynchronous services architecture for a data source are far greater than for a synchronous one. Additionally, in order to provide asynchronous notification to the wireless user when the event of interest has occurred, the data source is required to maintain a significant amount of state information (i.e. subscription information/filters, subscriber call-back address, etc.) and perform extensive calculations when internal state change events occur, such as matching event information with every subscription filter on record. These factors negatively affect availability and scalability of the system especially in the wireless space where the number of subscribers could easily reach several hundreds of thousands.
Accordingly, there is a need for a wireless alert or notification system, which is capable of using standard synchronous Web services.